home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 13963 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: lrz-muenchen.de!news
  2. From: watzka@stat.uni-muenchen.de (Kurt Watzka)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: problem: sun4 and hpux char * difference
  5. Date: 10 Apr 1996 21:31:01 GMT
  6. Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
  7. Distribution: world
  8. Message-ID: <4kh9al$drp@sparcserver.lrz-muenchen.de>
  9. References: <Dpnpn5.Lo3@Cadence.COM>
  10. NNTP-Posting-Host: sun2.lrz-muenchen.de
  11. Keywords: Help
  12.  
  13. tmccoy@nntp.cadence.com (Timothy McCoy) writes:
  14.  
  15. >I have a program that is made for hpux and sun4 users.
  16. >The sun program fails and the hpux version does not.
  17. >The problem stems from a struct definition that includes
  18. >a pointer to a char.  Something like:
  19.  
  20. >typedef struct record 
  21. >  {            
  22. >  struct rec        *first_rec ;
  23. >  char              *name   ; 
  24. >  } warn_record ;          
  25.  
  26. >After space is allocated for the record, typically, the
  27. >user will do something like this:
  28.  
  29. >lrec = (struct record *)calloc((unsigned)1,sizeof(struct record));
  30. >lrec->node_name = (char *) NULL;
  31.  
  32. Please note that you cannot be sure that first_rec is a NULL pointer
  33. if you decide to port this program to another platform but the two
  34. mentioned in your article. If you do _not_ care about whether the
  35. pointers are NULL pointers,
  36.  
  37.   lrec = malloc(sizeof *lrec);
  38.  
  39. should be good enough, and if you want safe and portable NULL pointers,
  40. you can add
  41.  
  42.   lrec->first_rec = NULL;
  43.   lrec->name = NULL;
  44.  
  45. >The problem is that, on the sun only, if I try to access
  46. >any of the standard string functions on this char * the 
  47. >program dies with a segmentation error. e.g.;
  48.  
  49. >(void) strcpy(astring, lrec->node_name ); /* fine on hp */
  50. >/* Segmentation fault (core dumped) on sun4 */
  51.  
  52. >I believe I understand why its dieing on the sun, as 
  53. >a null (zero) address can't be read from (really) but
  54. >myself and others thought that it was 'standard' to 
  55. >interpret it as zero and (in this example) copy '\0'
  56. >into astring, which is just what the hp does.  
  57.  
  58. The standard does not define what happens if you pass a
  59. NULL pointer to a function from the standard library
  60. that does not accept a NULL pointer. The behaviour 
  61. observed on HP machines is just _one_ possible implementation.
  62. They try to be helpful by writing an error tolerant
  63. library.
  64.  
  65.  
  66. >Could someone shed some light on this for me?
  67.  
  68. >Additionally, why, Why, WHY does the sun version of
  69. >this:
  70.  
  71. >printf("name='%s'\n", lrec->node_name);
  72.  
  73. >yield this:
  74.  
  75. >name='(null)'
  76.  
  77. >and hp yields a more reasonable:
  78.  
  79. >name=''
  80.  
  81. In this case, both implementors try to be helpful, but in a
  82. different way. AFAIK, there is no defined behaviour for 
  83. printf if a "(char *)0" is passed as an argument matching
  84. a "%s" format string.
  85.  
  86. Kurt
  87. --
  88. | Kurt Watzka                             Phone : +49-89-2180-6254
  89. | watzka@stat.uni-muenchen.de
  90.  
  91.